FIG. 1A schematically illustrates the logical architecture of an Optical Transport Network (OTN) in accordance with ITU-T recommendation G.8080/Y.1304, entitled Architecture for the Automatically Switched Optical Network (ASON), the entire content of which is incorporated herein by reference. As may be seen in FIG. 1A, the network 2 is logically divided into a transport plane 4 and a control plane 6.
The Transport Plane 4 comprises a plurality of switches 10 interconnected by Physical Interfaces (PIs) 12, and is responsible for transporting subscriber traffic via end-to-end connections provisioned through the network. The Control Plane 6 comprises an Optical Connection Controller (OCC) 14 associated with each switch 10 of the transport plane 4, and is responsible for resource and connection management within the transport plane 4. In the illustrated architecture, one OCC 14 is associated with a respective one switch 10 for clarity. In fact, the ASON permits an OCC 14 to manage multiple switches 10, if desired. Each OCC 14 is connected to its corresponding switch 10 of the transport plane 4 via a Connection Controller Interface (CCI) 16 which enables the respective OCC 14 to implement control plane functionality for its corresponding switch 10. Within the Control Plane 6, the OCCs 14 are interconnected via Network to Network Interfaces (NNIs) 18, and provide a set of network resource and connection management functions. These functions may, for example, include: network topology discovery (resource discovery); address assignment; path computation, connection set-up/tear-down; connection protection/restoration; traffic engineering; and wavelength assignment. Other management functions can be implemented by the control plane 6, as desired.
A physical node of the network will typically incorporate both a Transport Plane switch 10 and its corresponding Control Plane OCC 14, although this is not essential. In some cases, a Transport Plane switch 10 and its corresponding Control Plane OCC 14 may be provided in separate physical machines. For example, the respective OCCs 14 of one or more switches 10 may be hosted on a server (not shown).
Client premised equipment (CE) 20, which may be a server or a router, for example, can send and receive packets that contain information for both the Transport Plane 4 and the Control Plane 6. For this purpose, the CE may be connected to a switch 10 of the Transport Plane 4 via a PI 12, and to its corresponding OCC 14 via a User Network Interface (UNI) 22.
FIG. 1B presents a simplified view of the network architecture of FIG. 1A, in which the switches 10 and their associated OCCs 14 are represented by network nodes 24 connected by inter-node links 26 (each of which includes a PIs 12 and its corresponding NNI 18). Similarly, the CE 20 is represented as being connected to a network node 24 via an access link 28 which, in the illustrated embodiment, includes a PI 12 and a UNI 22.
Referring to FIG. 2, it is customary to extend the architecture of FIG. 1B to implement access gateways (AGs) 30 between the CEs 20 and the network 2. An access gateway 30 may also be referred to as an access server or an aggregation server. The function of the access gateway 30 is to provide an interface between one or more CEs 20 and the network 2. Among other things, an AG 30 enables a service provider to aggregate traffic flows to and from multiple CEs 20, which increases the number of CEs 20 that can access the network 2, while making better use of the bandwidth capacity of the access links 28 to the network 2. The use of an AG 30 also simplifies the implementation of dual-homed connections to the network 2, which has a benefit of removing a single point of failure in the path to and from the CEs 20. In the example of FIG. 2, AG-1 is dual homed to the network 2 via respective access links 28 to network nodes A and B, while AG-m is single-homed to the network 2 via an access link 28 to node B.
It would be desirable to extend the control plane 6 to include the AGs 30. This would be beneficial in that, among other things, each AG 30 would then be able to participate in topology discovery, path computation, connection set-up/tear-down and failure recovery functions offered by the OTN control plane 6. As is known in the art, topology discovery requires the exchange of link state messages between each of the OCCs 14 of the control plane 6, and the use of such state messages to accumulate a respective topology database for each OCC 14. Such topology database can then be used by an OCC 14 to compute connection routes through the network 2. Open Shortest Path First (OSPF) is a well-known protocol which defines various types of Link State Advertisement (LSA) messages that may be used for this purpose. Other protocols are also known, which also use inter-OCC messaging for topology discovery and route computation. For ease of description in this application, explicit reference will be made to LSA messages, it being understood that such references are also intended to encompass other message types and protocols that may be used in the control plane to implement topology discovery and route computation functions for the network 2.
In a full-mesh network, both the volume of LSA traffic and the size of the topology database increases with N2, where N is the number of nodes participating in the control plane 6. In a network environment in which there are a large number of AGs 30, extending the control plane 6 to include the AGs 30 can lead to a proliferation of LSA traffic and require a very large topology database, both of which may degrade the topology discovery, route computation, and failure recovery functions of the control plane 6.
Techniques that enable extension of the OTN control plane 6 without unduly degrading control plane performance, remain highly desirable.